카본 (API)

3. 구조

카본은 Toolbox에서 파생되었으며, "매니저"라고 불리는 기능적으로 관련된 API들의 집합으로 구성된다. 각 매니저는 데이터 구조와 이를 조작하는 함수 집합을 정의하며, 서로 상호 의존적이거나 계층화되어 있기도 하다.

카본은 애플이 맥 OS 기존 코드 기반에서 실제적이고 잘 지원되는 업그레이드 경로를 제공하기 위해 도입한 시스템이다. 카본은 맥과 유사한 API를 제공하지만, Mac OS의 복사본을 에뮬레이션으로 실행하는 것이 아니라, 기본 Unix와 유사한 OS 위에서 실행되는 여러 라이브러리와 함수로 구성된다. 카본 라이브러리는 광범위하게 정리되고 현대화되었으며 더 잘 "보호"되었다. Mac OS가 데이터를 전달하기 위해 메모리를 공유하는 API로 가득 찬 반면, 카본에서는 모든 그러한 접근이 접근자 메서드를 통해 재구현되었다. 이를 통해 카본은 진정한 컴퓨터 멀티태스킹과 메모리 보호를 지원할 수 있었는데, 이는 Mac 개발자들이 10년 동안 요청해 온 기능이었다.

카본을 지원하기 위해, 전체 Rhapsody 모델이 변경되었다. Rhapsody가 에뮬레이터와 함께 OpenStep였던 반면, 새로운 시스템에서는 OpenStep와 Carbon API가 가능한 경우 공통 코드를 공유하게 되었다. 이를 위해, Objective-C로 작성되어 Foundation으로 알려진 OpenStep 시스템의 하위 수준에서 유용한 코드 조각의 상당수가 순수한 C로 재구현되었다. 이 코드는 Core Foundation(CF)으로 알려지게 되었다. CF를 호출하도록 이식된 Yellow Box 버전은 새로운 코코아 API가 되었고, 카본의 Mac과 유사한 호출 또한 동일한 함수를 호출했다. 새로운 시스템에서 카본과 코코아는 동등한 위치에 있었다. 이 변환은 객체 메서드가 기본 C 라이브러리를 호출하면서 코코아의 성능을 저하시켰지만, 애플은 이러한 영향을 줄이기 위해 ''무료 브릿징''이라고 불리는 기술을 사용했다.^[1]

애플은 또한 라이선스 제한이 있는 디스플레이 포스트스크립트에서 라이선스 없는 쿼츠(디스플레이 PDF)로 그래픽 엔진을 이식했다.^[2] 쿼츠는 카본 또는 코코아에서 사용할 수 있는 네이티브 호출을 제공하며, Java 2D와 유사한 인터페이스도 제공했다. 기본 운영 체제 자체는 추가로 격리되어 다윈으로 출시되었다.

카본의 최신 부분은 개념적으로 훨씬 더 객체 지향적인 경향이 있으며, 대부분 Core Foundation을 기반으로 한다. HIView Manager(Control Manager의 상위 집합)와 같은 일부 매니저는 C++로 구현되지만 카본은 여전히 C API이다.

3. 1. 주요 구성 요소

QuickTime 팀이 API를 Mac OS X에 이식하기 위해 호환 레이어를 만든 것이 원형이 되었다. 그것이 스티브 잡스의 눈에 띄어 범용 호환 프레임워크 아이디어로 채택되었다. Toolbox API 중에서 분명히 레거시이고 잘 사용되지 않는 것은 폐지하고 내부 구조를 32비트를 전제로 재설계하였다(Toolbox는 16비트 코드이며 PowerPC의 성능에 발목을 잡고 있었다).

Carbon API를 이용한 응용 프로그램을 '''Carbon 응용 프로그램'''이라고 부른다. Mac OS X에 탑재된 또 다른 API인 Cocoa가 Objective-C 코드를 작성해야 하는 데 비해, Carbon API는 Classic Mac OS에서 유래한 인터페이스를 가지고 있어 C/C++에서도 사용할 수 있다. 기본적으로 Toolbox와 소스 코드 호환을 목표로 하고 있어 단순한 이식만 한다면 그렇게 큰 설계 변경은 필요하지 않았다.

Carbon 응용 프로그램에는,

• 하나의 바이너리로 Mac OS X에서도 Classic Mac OS에서도 실행할 수 있는 『'''PEF Carbon'''』
• Mac OS X 전용 『'''Mach-O Carbon'''』

3. 2. Carbon 매니저

4. 이벤트 처리

클래식 Mac OS의 툴박스 이벤트 관리자는 원래 폴링 모델을 사용하도록 설계되었다. 애플리케이션의 메인 이벤트 루프는 이벤트 관리자에게 `GetNextEvent`를 사용하여 이벤트를 요청한다. 큐에 이벤트가 있으면 이벤트 관리자가 이를 애플리케이션에 전달하여 처리하고, 그렇지 않으면 즉시 반환한다. 이러한 동작은 "바쁜 대기"라고 하며, 불필요하게 이벤트 루프를 실행한다. 바쁜 대기는 다른 애플리케이션에 사용 가능한 CPU 시간을 줄이고 랩톱의 배터리 전원을 감소시킨다. 클래식 이벤트 관리자는 1984년 최초의 Mac OS에서 시작되었으며, 당시 실행 중인 애플리케이션이 ''유일한'' 실행 중인 애플리케이션으로 보장되었고, 전원 관리는 고려 사항이 아니었다.

MultiFinder가 등장하고 둘 이상의 애플리케이션을 동시에 실행할 수 있게 되면서 새로운 이벤트 관리자 호출인 ''WaitNextEvent''가 도입되었으며, 애플리케이션은 절전 간격을 지정할 수 있다. 레거시 코드가 소스 코드를 크게 변경하지 않고도 더 효율적인 모델을 채택하는 쉬운 방법은 ''WaitNextEvent''에 전달된 절전 매개변수를 매우 큰 값으로 설정하는 것이다. macOS에서는 아무것도 할 일이 없을 때 스레드를 절전 상태로 만들고, 처리할 이벤트가 있을 때만 이벤트를 반환한다. 이러한 방식으로 폴링 모델은 애플리케이션이 원래 방식대로 자체 이벤트 디스패칭을 수행하는 콜백 모델과 동일하게 빠르게 전환된다. 그러나 허점이 있다. 예를 들어, 레거시 툴박스 호출인 ''ModalDialog''는 내부적으로 이전의 ''GetNextEvent'' 함수를 호출하여 차단 없이 타이트 루프에서 폴링이 발생한다.

카본은 카본 이벤트 관리자라는 대체 시스템을 도입한다. (원래 이벤트 관리자는 레거시 애플리케이션과의 호환성을 위해 여전히 존재한다). 카본 이벤트 관리자는 개발자를 위한 이벤트 루프를 제공한다(현재 구현에서 코어 파운데이션의 `CFRunLoop` 기반). 개발자는 이벤트 핸들러를 설정하고 메인 함수에서 이벤트 루프에 들어가 카본 이벤트 관리자가 애플리케이션에 이벤트를 디스패치할 때까지 기다린다.

5. 타이머

클래식 Mac OS에서는 응용 프로그램 수준 타이머에 대한 운영 체제 지원이 없었다. (하위 수준 Time Manager는 사용 가능했지만, 인터럽트 시에 타이머 콜백을 실행했으며, 이 동안 대부분의 툴박스 루틴을 안전하게 호출할 수 없었다.)^[1] 타이머는 일반적으로 응용 프로그램 개발자가 구현해야 했으며, 이는 주로 '유휴' 이벤트(다른 이벤트가 없을 때 `WaitNextEvent`에 의해 반환되는 이벤트) 동안 경과 시간을 계산하는 방식으로 수행되었다.^[1] 이러한 타이머가 합리적인 해상도를 가지려면 개발자는 `WaitNextEvent`가 너무 오래 지연되는 것을 막기 위해 낮은 "sleep" 매개변수를 설정해야 했다.^[1] 이는 스레드가 오랫동안 잠들지 않고 유휴 이벤트를 반환하기 위해 반복적으로 깨어나게 만들어 매우 비효율적인 스케줄링 동작을 초래했다.^[1] 애플은 이 문제를 해결하기 위해 카본에 타이머 지원을 추가했으며, 시스템은 매우 효율적으로 타이머를 예약할 수 있게 되었다.^[1]

6. 오픈 소스 구현

GNUstep은 Boron이라고 불리는 Carbon API의 구현을 포함하고 있다. 이는 ApplicationServices와 CoreServices의 더 이상 사용되지 않는 부분을 제외한 부분과의 호환을 목표로 한다. Boron이 주기율표에서 Carbon보다 먼저 나온다는 사실에서 이름이 유래되었다.^[14] Darling 역시 Carbon 구현을 포함하고 있다. 두 구현 모두 매우 불완전하며 주로 스텁 함수로 구성되어 있다.

참조

_[1] 웹사이트 Concepts in Objective-C Programming: Toll-Free Bridging https://developer.ap[...] 2017-05-08
_[2] 웹사이트 Mac OS X Update: Quartz & Aqua http://archive.arste[...] 2017-05-08
_[3] 웹사이트 Apple moving Finder to Cocoa http://www.cnet.com/[...] 2008-10-17
_[4] 웹사이트 Introduction to 64-Bit Guide for Carbon Developers https://developer.ap[...]
_[5] 웹사이트 Choosing a Development Path for Your Carbon User Interface https://developer.ap[...]
_[6] 웹사이트 Rhapsody and blues https://arstechnica.[...] 2023-02-05
_[7] 웹사이트 Photoshop, Lightroom, and Adobe's 64-bit roadmap http://blogs.adobe.c[...]
_[8] 웹사이트 iTunes 10 hands-on: snappier performance, questionable UI choices https://arstechnica.[...] 2010-09-03
_[9] 웹사이트 Mac OS X 10.6 Snow Leopard: the Ars Technica review https://arstechnica.[...] 2009-09
_[10] 웹사이트 64-bit Requirement for Mac Apps https://developer.ap[...] 2018-02-18
_[11] 웹사이트 32-Bit Apps 'Not Optimized for Your Mac' to Stop Working on macOS Catalina https://www.macrumor[...] 2019-08-10
_[12] 웹사이트 Apple Carbon homepage https://developer.ap[...]
_[13] 문서 HIEditText SOM class description from Mac OS 8.0 (Copland) DDK http://octagram.name[...]
_[14] 웹사이트 gnustep/libs-boron: Boron is the atom that comes before carbon. https://github.com/g[...] GNUstep 2019-03-23
_[15] 문서 CFMやMach-Oは[[アプリケーションバイナリインタフェース|ABI]] (Application Binary Interface) のことで、[[アプリケーションプログラミングインタフェース|API]] (Application Programming Interface) とは無関係。
_[16] 문서 Choosing a Development Path for Your Carbon User Interface http://developer.app[...]